Общий курс · осенний семестр · занятие 11 из 15

UI/UX: свой файл правил для LLM

О чём эта тема: Продолжение эксперимента занятия 10: законы UX превращаются из знаний в инструмент — файл правил (skill-файл), который подключается к LLM-агенту и заставляет его генерировать интерфейсы без типовых нарушений.
Аннотация: Сначала разбирается формат skill-файла — как агенты вроде Claude Code и DeepSeek-агентов читают файлы SKILL.md: обязательный заголовок с именем и описанием, ограничения на объём, принцип «что делает + когда применять». Затем — главное ремесло занятия: превращение закона UX в правило для машины по фиксированной форме из четырёх слотов — КОГДА + СДЕЛАЙ + МЕРА + ПРОВЕРКА — с разобранным примером. Тренажёр предлагает найти нарушенный закон в шести нарочно испорченных макетах. Задание — дополнить файл-заготовку правилами по всем одиннадцати законам, применить его к промпту из занятия 10 и сравнить результаты «до» и «после».
Пререквизиты: Выполненное задание занятия 10: понадобится ваш отчёт о деградациях и то же техническое описание экрана «Расписание занятий».
Мотивация: На занятии 10 вы были критиком: находили нарушения после генерации. Критик приходит поздно — ошибки уже сделаны. Инженерный подход — профилактика: один раз записать правила так, чтобы модель применяла их к каждому экрану сама. Такой файл — многоразовый инструмент: написали один раз, работает в каждом проекте.

1. Skill-файл: как агенты читают правила

Просить LLM «сделай красиво и удобно» бесполезно — это вкус, а не инструкция. Современные LLM-агенты (Claude Code, агенты на базе DeepSeek и другие) решают задачу иначе: рядом с проектом лежат файлы навыков (skills) — обычный Markdown с правилами, который агент подхватывает, когда задача подходит под описание навыка. Открытая спецификация такого файла называется SKILL.md; её поддерживает целое семейство инструментов, включая DeepSeek-агентов (папки ~/.agents/skills/<имя>/SKILL.md или .deepcode/skills/ внутри проекта).

Устройство файла:

--- заголовок (YAML frontmatter) — единственная обязательная часть ---
---
name: ui-ux-laws
description: Правила проектирования интерфейсов по законам UX.
  Использовать при генерации, вёрстке или ревью любого экрана…
---

# дальше — обычный Markdown: правила, примеры, чек-листы

Формальные требования спецификации:

Часть файла	Требование	Зачем
`name`	Обязательно. 1–64 символа по маске `[a-z0-9-]` (латиница в нижнем регистре, цифры, дефисы); совпадает с именем папки навыка.	Идентификатор: по нему навык находится, подключается и упоминается в логах агента.
`description`	Обязательно. До 1024 символов; строится по формуле «что делает + когда использовать» и содержит ключевые слова будущих запросов («интерфейс», «экран», «HTML», «макет»).	Единственное, что агент видит всегда: по нему решается, доставать ли навык для текущей задачи.
тело файла	Обычный Markdown, рекомендация — не длиннее ~500 строк; объёмные справочники — в соседние файлы со ссылками из тела.	Читается целиком только после срабатывания навыка (прогрессивное раскрытие) — компактность экономит контекст модели.
размещение	Папка с именем навыка: `~/.agents/skills/<name>/SKILL.md` (глобально) или `.deepcode/skills/<name>/SKILL.md` (в проекте).	Агент сканирует эти пути при старте — файл в другом месте просто не будет найден.

Типичная ошибка Написать в description «полезные правила дизайна». Агент сопоставляет описание с задачей: по такой формулировке навык не сработает ни на «сверстай экран расписания», ни на «сделай форму логина». Описание пишется не для человека, а для выбора навыка машиной — глаголы и предметные слова обязательны.

2. Из закона — в правило

Скопировать в skill-файл теорию из занятия 10 — не решение: модель прочитает историю про стилус Пола Фиттса и сгенерирует всё ту же крошечную кнопку. Закон нужно переписать в императив — короткое указание, выполнение которого можно проверить, глядя на результат. Сравните:

так не работает «Закон Фиттса гласит, что время достижения цели зависит от расстояния до неё и её размера, поэтому важно учитывать эргономику размещения элементов».

так работает «Самое частое действие экрана — самый крупный интерактивный элемент; размещай его рядом с местом принятия решения. Сенсорная цель — не меньше 44×44 px».

так не работает «Помни о законе Хика: большое количество вариантов увеличивает когнитивную нагрузку на пользователя».

так работает «Больше 7 равнозначных опций одновременно не показывать: сгруппируй по категориям или разбей выбор на шаги».

Чтобы не изобретать формулировку каждый раз заново, зафиксируем форму правила. Каждое правило собирается из четырёх слотов:

ПРАВИЛО = КОГДА + СДЕЛАЙ + МЕРА + ПРОВЕРКА

КОГДА     ситуация, в которой правило применяется
СДЕЛАЙ    императив: один глагол — одно действие
МЕРА      число или порог, если он существует (иначе слот пропускается)
ПРОВЕРКА  вопрос к готовому экрану, на который отвечают «да» или «нет»

Разберём по слотам одно правило из закона Фиттса:

Слот	Содержимое
когда	на экране есть главное действие (оплатить, отправить, сохранить)
сделай	сделай его самым крупным интерактивным элементом и размести рядом с местом, где пользователь принимает решение
мера	сенсорная цель не меньше 44×44 px
проверка	самая крупная кнопка экрана — это главное действие?

В файле навыка эти слоты склеиваются в один пункт списка — именно в таком виде правило и пишется:

## Закон Фиттса

- Когда на экране есть главное действие (оплатить, отправить, сохранить) —
  сделай его самым крупным интерактивным элементом рядом с местом принятия
  решения; сенсорная цель — не меньше 44×44 px.
  Проверка: самая крупная кнопка экрана — это главное действие?

Форма отсекает типовые дефекты сама: пункт без глагола не собирается (нет слота СДЕЛАЙ), «делай удобно» не проходит слот ПРОВЕРКА (на «удобно?» нельзя ответить да/нет), а правило с тремя «и» не помещается в один слот СДЕЛАЙ — его придётся разрезать на три пункта, что и требовалось.

Источник содержимого для слотов у вас уже есть: практические следствия каждого закона из раздела 2 занятия 10 плюс ваш собственный отчёт о деградациях — каждая найденная там проблема просится стать правилом-запретом («Когда в списке больше 7 фильтров — …»).

3. Тренажёр: найди нарушение

Прежде чем писать правила, стоит проверить, распознаёте ли вы нарушения с одного взгляда. Шесть макетов, в каждом испорчено что-то одно.

Тренажёр · какой закон нарушен?

Рассмотрите макет и выберите закон, который в нём нарушен. После ответа — пояснение и следующий макет.

Разбор не начат.

4. Задание: файл правил и эксперимент «до/после»

Заготовка файла со структурой и тремя заполненными законами: скачать z11_skills_template.md. Правила по Фиттсу, Хику и фон Ресторфф уже написаны как образец; остальные восемь разделов помечены TODO.

Задание · практика 11

Дополните заготовку. По каждому TODO-разделу — 2–3 правила строго по форме из раздела 2: КОГДА + СДЕЛАЙ + МЕРА + ПРОВЕРКА. Обязательно добавьте правила-запреты из вашего отчёта о деградациях с занятия 10.
Проверьте заголовок файла: name из латиницы, цифр и дефисов; description по формуле «что делает + когда использовать».
Повторите генерацию из занятия 10, приложив к тому же описанию экрана «Расписание занятий» ваш файл правил (в чате — просто вторым файлом или текстом после промпта; в агенте — положив его как skill).
Сравните «до» и «после» той же таблицей по элементам экрана: какие нарушения исчезли, какие остались, появились ли новые.
Разберите остатки. Для каждого выжившего нарушения решите, в чём причина: правило не написано? написано непроверяемо? модель его проигнорировала? Уточните формулировки и прогоните ещё раз.
Итог — ваш файл правил + таблица «до/после» + вывод в три-четыре предложения: какие формулировки правил работают, какие нет.

Типичная ошибка Мерить успех количеством правил. Файл из сорока расплывчатых пунктов работает хуже файла из пятнадцати проверяемых: модель, как и человек, выполняет короткие однозначные указания и теряется в длинных туманных. Если после «уточнения» правило стало длиннее втрое — вы пересказали теорию, а не написали правило.

Контрольные вопросы

name — идентификатор навыка (латиница в нижнем регистре, цифры, дефисы; совпадает с именем папки) и description — описание «что делает + когда использовать», по которому агент решает, подключать ли навык к текущей задаче.
Тело агент читает только после того, как навык сработал, а срабатывание определяется сопоставлением description с задачей пользователя. Идеальные правила в теле бесполезны, если описание не содержит слов, по которым навык будет выбран.
КОГДА (ситуация применения), СДЕЛАЙ (императив, один глагол — одно действие), МЕРА (число или порог, если есть), ПРОВЕРКА (вопрос к экрану с ответом да/нет). «Делай удобно» не проходит слот ПРОВЕРКА: на вопрос «удобно?» нельзя ответить да или нет, глядя на экран.
По механике почти ничем — правила попадают в контекст модели. Разница в многоразовости и автоматике: файл написан один раз, подключается к любой задаче, подходящей под description, и не зависит от того, вспомнил ли автор промпта о правилах в этот раз.
Правила на этот случай нет вообще; правило есть, но сформулировано непроверяемо («делай удобно»); правило проверяемое, но модель его проигнорировала — тогда помогает переформулировка, перемещение ближе к началу файла или явное требование самопроверки по чек-листу.

Источники

Agent Skills : открытая спецификация SKILL.md : [сайт]. — URL: https://agentskills.io/ (дата обращения: 08.07.2026).
SKILL.md Specification // DeepWiki : agentskills/agentskills : [сайт]. — URL: https://deepwiki.com/agentskills/agentskills/2.2-skill.md-specification (дата обращения: 08.07.2026).
Awesome DeepSeek Agent // GitHub : deepseek-ai : [сайт]. — URL: https://github.com/deepseek-ai/awesome-deepseek-agent (дата обращения: 08.07.2026).
Восемь именных законов в UX дизайне. Часть 1 // Хабр : [сайт]. — URL: https://habr.com/ru/companies/dbtc/articles/443306/ (дата обращения: 08.07.2026).
Восемь именных законов в UX дизайне. Часть 2 // Хабр : [сайт]. — URL: https://habr.com/ru/companies/dbtc/articles/456680/ (дата обращения: 08.07.2026).